REMARKS 

In the Office Action dated April 18, 2007, claim 14 was rejected under 35 
U.S.C. §112, second paragraph as being indefinite because of being directed to a 
"data carrier," whereas the Examiner stated the body of the claim recites elements of 
the mail-processing device. 

In response, claim 14 has been amended to claim to claim a computer- 
readable medium encoded with a data structure, so that claim 14 is in conformity 
with the requirements for patentable subject matter expressly stated in MPEP 
2016.01.1. In that section, in addition to stating that a computer-readable medium 
encoded with a data structure is patentable subject matter under 35 U.S.C. §101, it 
is expressly stated that such a data structure, in order to be statutory subject matter, 
must define structural and functional interrelationships between the data structure 
and the computer software and hardware components, which permit the data 
structure's functionality to be realized. Therefore, in this context, it is not only 
permissible, but is required, to describe interaction between the data structure and 
the software and hardware components. Therefore, the Examiner's objection to the 
limitation of "loadable from the data carrier into the programmable memory" is not 
proper, either under §1 12 or under §101. 

Claim 14, therefore, is submitted to be directed to statutory subject matter 
under 35 U.S.C. §101 as well as being in compliance with all provisions of §112, 
second paragraph. 

Claims 1, 2, 7, 9 and 10 were rejected under 35 U.S.C. §1 02(b) as being 
anticipated by Uno et al. This rejection is respectfully traversed for the following 
reasons. 
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The subject matter disclosed and claimed in the present application is a mail- 
processing device that allows a product code to be automatically retrieved from a 
memory, upon the entry of shipping information into the mail-processing device and 
to supply, as an output, text for the product description for generating a printout 
thereof. 

The term "product code" is a term with a specific, well-documented meaning 
in the context of mail processing. As explained in the first full paragraph at page 3 of 
the present specification, a product code is a specific definition pertaining to a 
specific mailing category that is defined by the governmental postal authorities in 
some countries, such as in Germany and in Canada. The product code designates 
additional services, beyond basic mailing, that are requested by the mailer, such as 
overnight delivery, registered mail, etc. The product code must be included in the 
franking imprint according to the postal regulations in these countries, but this code 
is simply a number and therefore does not, by itself, provide explanatory information 
to a user who has not memorized all of the relevant product codes. As explained at 
page 3 of the present specification, this therefore necessitates extra steps by the 
user in generating the franking imprint. 

A copy of relevant pages from the document entitled "FRANKIT: New 
Generation Digital Franking," Version 1.3, May 15, 2003, published by Deutsche 
Post, is attached hereto as Exhibit "A", describing the product code and the 
requirements for its inclusion in the franking imprint. 

The United States, via the USPS, currently does not require such a product 
code. The Examiner can verify this if the Examiner wishes by reviewing the USPS 
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Knowledge Base at http://pe.usps.com and the documentation of United States 
postal rates at http://www.usps.com/rates/welcome.htm. 

The use of such product code entries is described in the present specification 
in the paragraph bridging pages 4 and 5, and the advantage achieved by the present 
application of allowing automatic selection and inclusion of an appropriate product 
code entry in the printing information is described in the present specification at 
numerous locations, and is summarized in the paragraph bridging pages 5 and 6 of 
the present specification. 

As noted above, the "invention" of such product code entries and the 
governmentally-required inclusion thereof, in certain countries, in the franking 
information that is printed on a mail item, is relatively recent. The Uno et al. 
reference relied upon by the Examiner was filed in the United States Patent and 
Trademark Office on July 15, 1994, and is based on a Japanese priority application 
filed on July 16, 1993. This is much too early for the subject matter disclosed in that 
reference to have any applicability whatsoever to product code entries, and certainly 
there is no description in that reference of product code entries, since product code 
entries did not even exist at the time the application that issued as the Uno et al. 
application was prepared. 

As explained in the present specification, the product code entry is simply a 
number, and there are many such numbers that respectively represent the different 
types of services that are available, and that are respectively identified by different 
product codes. For the user of a franking machine, this means that, assuming the 
user has not memorized the entire list of product codes, the user must enter the 
shipping information into a postage machine for a particular mail item, in order to 
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enable the postage machine to calculate the appropriate postage and generate a 
franking imprint for the mail item, and the user must then also consult another 
memory that has all of the product codes listed therein so as to select and enter the 
appropriate product code. The present invention automates this function, so that the 
user is relieved of having to memorize the list of product codes and/or having to 
consult an additional menu and then make an additional data entry into the postage 
meter machine. 

Independent claim 1 has been amended to better define the interrelationship 
and interoperation of the claimed elements, particularly with respect to the automatic 
inclusion of an appropriate product code in the print data that will be used to 
generate the franking imprint for the current mail item. 

Since the Uno et al. reference does not, and could not (by virtue of the time at 
which that document was created), make any reference whatsoever to product code 
entries, none of claims 1, 2, 7, 9 or 10 is anticipated by the Uno et al. reference. 

Claims 3-6 and 14 were rejected under 35 U.S.C. §1 03(a) as being 
unpatentable over Uno et al. in view of Guenther et al. This rejection is traversed for 
similar reasons as discussed above with regard to the anticipation rejection. The 
Guenther et al. reference, like Uno et al., was generated before product entry codes 
were even known, and therefore has not applicability to the problem of automated 
inclusion of the an appropriate product code entry in the print data for an item being 
mailed. Therefore, a combination of Uno et al. and Guenther et al. would not result 
in the subject matter of any of claims 3-6, all of which depend from independent 
claim 1 and incorporate the subject matter of independent claim 1 therein, nor claim 
14, which also specifically refers to the storage and retrieval of product codes. 
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Claims 8 and 11-13 were rejected under 35 U.S.C. §1 03(a) as being 
unpatentable over Uno et al. in view of the Examiner taking Official Notice "that it 
would have been prima facie obvious to one having ordinary skill at the time of the 
invention to incorporate the operating mode into the device by actuating an operating 
element of a keyboard." The above arguments regarding the Uno et al. reference 
are applicable to this rejection as well, but Applicant further respectfully submits that 
the way this rejection is formulated is an abuse of the "Official Notice" doctrine. The 
"Official Notice" doctrine is for the purpose of permitting the Examiner to take "Official 
Notice" of information and facts that are so well-known or commonplace that it is not 
necessary for the Examiner to expend the time to locate a specific reference that 
cites such information or facts. The purpose of the doctrine of "Official Notice" is 
solely for the purpose of permitting the Examiner to shorten his or her search time by 
not having to search the prior art for such commonplace items. It is not permitted 
under the doctrine of "Official Notice" to take "Official Notice" of the alleged 
obviousness of making a particular modification of, or addition to, a reference. If this 
were the case, the Examiner would never have to substantiate an obviousness 
rejection with appropriate evidence. The Examiner is permitted to take "Official 
Notice" of a particular fact or item of information, but then must use that fact or 
information in the same way as if it were being cited in a reference. The Examiner is 
not permitted to take "Official Notice" that it would have been prima facie obvious..." 
as the Examiner has done in the rejection of claims 8 and 11-13 in the sentence 
bridging pages 10 and 1 1 of the Office Action. 

In view of the above discussion relating to the Uno et al. reference, however, 
even if the Examiner made proper use of the doctrine of "Official Notice," modifying 
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the Uno et al. reference in accordance with the information of which the Examiner 
has taken "Official Notice" still would not result in the subject matter of any of claims 
8 or 11-13. 

All claims of the application are therefore submitted to be in condition for 
allowance, and early reconsideration of the application is respectfully requested. 

The Commissioner is hereby authorized to charge any additional fees which 
may be required, or to credit any overpayment to account No. 501519. 

Submitted by v 




SCHIFF, HARDIN LLP 
CUSTOMER NO. 26574 

Patent Department 
6600 Sears Tower 
233 South Wacker Drive 
Chicago, Illinois 60606 
Telephone: 312/258-5790 
Attorneys for Applicant. 
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be left aligned to that anchor point. Consequently, the distance between 
the right edge of the international variant of the barcode and the left edge 
of the matrix code will measure 13.25 mm. If printers are used with other 
resolutions than 300 dpi, the width of the barcode may vary. If a barcode 
must be wider than 47.25 mm, then the left edge of this barcode will 
move to the left, still ensuring a distance of 5 mm between the barcode's 
right edge and the matrix code's left edge. If the width of the code is 
smaller than 47,25 mm, the dimensions as stated above in the first part of 
this paragraph will be valid (the code will not move to the right). Content 
and specification of the barcode will be covered in section 7. 

# The big letter "R" is used as to indicate additional services. The text must 
be in sans serif, regular-style Arial font with an uppercase letter height of 
11.0 mm, resulting in a width of 10 mm. The distance between the left 
edge of the character and the left edge of the barcode measures 15 mm. 
This distance ensures that there is a minimum blank space of 5 mm left 
of the barcode. 

„ There is a 1-pt strong line or stroke above the barcode, which has the 
same width as the barcode used (i.e., 47.25 or 39 mm). The center of the 
stroke is 1 mm above the upper edge of the barcode. 

* The barcode content is repeated in plain text above the line or stroke 
over the barcode. Text must be in sans serif, regular-style Arial font with 
an uppercase letter height of 2,0 mm. The distance between the center of 
the stroke and the lower edge of the plain text line is 1 mm, which means 
that the distance between the lower edge of the plain text line and the 
upper edge of the barcode is 2 mm. The plain text line starts 7 mm right 
of the left edge of the barcode, This position will ensure that plain text is 
almost centered over both the domestic and international versions of the 
barcode. For improved readability, plain text information is grouped. The 
first group holds two uppercase letters. The second group, consisting of 
two digits, follows after two blank spaces. The following two groups of 
three digits each are both separated by one blank space. After another 
two blank spaces, a three-character group follows, which contains the 
check number and two tetters for the country code. Only in the case of 
domestic additional services does a final group of three digits containing 
the product code follow, again separated by two blank spaces, 

« The additional services are displayed in clear text in two lines, which 
are left aligned with the barcode. The distance between the lower edge of 
the lower line and the upper edge of the barcode measures 5.5 mm. The 
line space between the lower and the upper line is 3 mm. For domestic 
additional services, text must be in italicized, sans serif, uppercase Arial 
letters with an uppercase letter height of 2.0 mm. For International addi- 
tional services, upper- and lowercase characters must be used in regular 
style, with an upper case letter height of 1.75 mm. For separation of two 
different additional services, two blank spaces will be introduced. If only 
one line is needed, the lower of both lines must be chosen. There must 
be a minimum distance of 3 mm between the text and the matrix code. 
Section 7.2 describes how the two lines have to be filled. 
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The franking imprint must not be printed on dark paper or very fibrous paper 
(such as recycled paper, because the matrix code can easily smear). 
The print on the franking imprint should be in a resolution of 300 dpi and in blue 
ink (as per specification) and on white or other pale-colored paper. 
Franking imprints printed on units working to a lower resolution may not meet 
quality requirements. The test requirements are applicable and must be ob- 
served. 



2.5.5 Test prints 

A digital franking meter can produce test prints, i.e., franking imprints which ap- 
pear to be valid franking imprints but are not intended for consignments; they 
serve as control prints and are useful for fine adjustment of the printer. 
In this case, the franking meter must ensure that Deutsche Post does not recog- 
nize such franking imprints as valid franking imprints. This is achieved by posi- 
tioning the word 'MUSTER' (sample) across the matrix code. For test prints, the 
data contents of the matrix code must be rendered illegible, either by the inscrip- 
tion mentioned above or by other means, in addition, the font format for the 
postage amount must be set to 'strike through' to ensure the postage amount is 
crossed out on any such test prints produced. 

Apart from real (paid) franking imprints and specially marked test prints, no nil 
value imprints may be produced. 

2.5.6 Franking process 

To create a digital franking imprint, it is necessary to select a particular product. 
The product is identified by a product code supplied by Deutsche Post, which is a 
unique code corresponding to a combination of basic product plus additional ser- 
vice^). The product code is incorporated into the matrix code and into the usage 
profile (see sections 4.2 and 4.1 1). 

If mail is to be franked on behalf of a third party or if a franking meter is jointly 
used by a third party, then the Deutsche Post's customer number (EKP no.) of 
the third party must be entered into the franking meter. Entering an EKP no. 
might also be required for using special products in the future. If Deutsche Post 
issues a job number for franking (no matter whether mail is franked for or by a 
third party or not), then the job number must be entered into the franking meter. 
If both EKP and job number are applicable, only the job number has to be en- 
tered. Any of these entries must be executed before starting the franking proc- 
ess. 

If a return answer letter is franked, the recipient's postal code must be entered 
into the franking meter. 

2.6 Hardware and software security requirements 

Intrinsic franking meter security is assured by the tamper-proof, protected area 
within the franking meter and the "cryptographic module," which conforms to the 
parameters described in FIPS PUB 140-2, level 3, Security Requirements for 
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4.2 The matrix code on a franking imprint 

Version 1 of the matrix code (vgl. Byte f4) contains 84 bytes: f1 to f84 



Byte no. 


Length 


Meaning 


Data content 


Comments 


f1, f2, f3 


3 


Post company 
(ASCII) 


„DEA" 
(ASCII) 
or 

'44 45 41' 


Deutsche Post AG 












Byte no. 


Length 


Meaning 


Data content 


Comments 


f4 


1 


Type and version 
of franking 


'03* 


Meter franking (FRANKIT), Version 1 

The latest type and can be taken from s4 of 

the Service ID, see section 4.6. 


Byte no. 


Length 


Meaning 


Data content 


Comments 


f5 


1 


Version of products/prices 


'XX 1 


The current version of products and prices 
has to be mentioned here. The latest ver- 
sion number can be taken from s5 of the 
Service ID, see section 4.6. i 


Byte no. 


Length 


Meaning 


Data content 


Comments 


f6 


1 


Supplier identification 


'XX 1 


Assigned by Deutsche Post to every sup- 
plier. 


f7 


1 


Model no. 


'XX' 


To be used by every supplier for each new 
model by arrangement with Deutsche Post, 
starting at '01' (first model) and increasing. 


f8, f9, f10 


3 


Model device number 


'XX XX XX' 


To be used by every supplier for each 
model starting at '00 00 01' and increasing 
to 'FF FF FF'. 










Bytes f6 to f10 correspond to the franking 
machine serial number (i.e. the first 5 bytes 
of the meter ID), see section 4. 1 . 
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Byte no. 


Length 


Meaning 


Data content 


Comments 


f11, f12 


2 


Fee or franked value 


'XX XX' 
in the format 

r~ r" J™ r-> r"\ 

EEECC 
(decimal) 


Decimal representation of the franked val- 
ue, currency as per currency indicator. 
(E - digits before and C ~ digits after the 
decimal point). 
Example: 0.56 Euros: 
decimal: 00056; hexadecimal: '00 38' 


Byte no. 


Length 


Meaning 


Data content 


Comments 


f13, f14 


2 


Franking date 


'XX XX' 

in the format 
DDDYY 
(decimal) 


Date format: decimal representation of the 
year in the format DDDYY, whereby "DDD" 
represents the current day in the year (up to 
365 or 366) and U YY" represents the last 
two digits of the year. 
(Example: 24 th July 2003, i.e. 205 th day in 
the year 2003; decimal: 20503; hexadeci- 
mal: '50 17') 


Byte no. 


Length 


Meaning 


Data content 


Comments 


f15, fl6 


2 


Product code 


'XX XX' 


The product code is used to assign the 
franking printout to a particular product 
group. A separate description of the product 
code and a list of product groups to use is 
given in section 4.8. 


Byte no. 


Length 


Meaning 


Data content 


Comments 


f17 


1 


Key phase indicator 


'XX' 


Only for internal post purposes. Value to be 
taken unaltered from the current Postage 
ID, see section 4.3. 


oy it? i iu. 


Length 


Meaning 




wxJf l il 1 1 til } l-b 


no 


1 


Currency indicator 


'01' 


Euro 










Value to be taken unaltered from the cur- 










rent Postage ID, see section 4.3. 
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4. 7 Hash total, truncated (security information) 

A hash total is formed to provide security for normal franking (see section 4,2) 
and the "account franking" (see section 4.9). The hash total is generated in the 
protected area of the franking meter using the franking data to be protected and 
the fiWet key information, which is securely stored in the protected area. 

The hash total is formed within the protected area of the franking meter by com- 
bining 80 bytes of unsecured information with the 16-byte long Postage ID and a 
the 16 bytes of (decrypted) nrWet security information, Thus, in total the hash al- 
gorithm will be applied to 1 12 bytes of data. 

When forming the hash total in order to secure a normal franking matrix code, 
the first 80 bytes of the matrix code (f1 to f80) have to be taken. 

When forming the hash total in order to secure the account franking, the first 80 
bytes of the account franking (a1 to a80) have to be taken. Although the Postage 
ID is already a component of the account franking, it will again be added for the 
creation of the hash total for reasons of consistency. So the hash total of the ac- 
count franking will also be generated by combining the 80 bytes with the 16-byte 
long Postage ID and a the 16 bytes of unencrypted trw* security information. 

Digital meters must be capable of securing the account franking by creating a 
hash total. The hash total will only be created upon request by the Postage Point, 
see section 5.5.2. 

SHA-1 is used for the generation of a hash total The Secret Suffix Method has 
to be applied (this means that the nWet security information is tagged on at the 
end). The first four bytes of the resultant hash total are incorporated into the ma- 
trix code as "truncated hash". 



4.8 Product codes 

Deutsche Post will provide the 2-byte product code in the form of a table. 



Byte no. 


Length 


Meaning 


Data content 


Comments 


ps1, ps2 


2 


Basic product with addi- 


'XX XX 1 


Deutsche Post will provide the supplier with 






tional services 




a table. 






(taking into account the 










destination, dimensions 










and weight) 







Note: The product code will indicate whether or not an additional services imprint 
is printed together with the franking imprint. Therefore, identical combinations of 
basic products and additional services will require different product codes 
depending on the kind of imprint. 

The table of product codes provided in digital form by Deutsche Post contains 
product codes in decimal representation, description, postage fee, additional in- 
formation (size and weight), and plain text to be included in the franking imprint 
for all possible combinations of basic products and additional services, see sec- 
tion 6.4. 
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Year/Month 


Product code 


Number of frankings 


Total revenue 


Customer Number 
{EKP no) 


Date format: 


'XX XX' (2 bytes) 


Numerical represen- 


Numerical represen- 


Numerical represen- 


YYYYMM 


Product code of the 


tation of the number 


tation of the total 


tation of the postal 


numeric in ASCII 


franking marks pro- 


of given products 


revenue for a given 


EKP customer num- 


format. 


duced (corresponds 


franked in this period, 


product during this 


ber in ASCII format if 




to the product code 


in ASCII format. 


period, in ASCII for- 


the franking is per- 


Example: July 2002 


on the franking print- 




mat. 


formed on behalf of 


is represented as: 


out). Represented in 




The last two digits are 


or by a third party, 


200207 


half-bytes 




to be read as the dig- 


then their customer 








its after the decimal 


number (EKP no.) 








point. 


should be supplied to 








Currency as per cur- 


Deutsche Post as 








rency indicator in the 


part of this entry. 








account franking 


If the franking is in 










the customer's own 










name, this informa- 










tion needs not to be 










given. 



Example: 

Year/Month Product code Number of frankings Total revenue Customer Number 
^^ mmmm ^^ (EKP no.) 



200207 


'oo or 


110 


6160 




200207 


'00 02' 


240 


26880 




200207 


'00 02' 


240 


26880 


5111111111 


200208 


'00 02' 


110 


12320 




Etc. 











4. 12Structure of a signed licence (without Remote Setting Center) 

In the model without Remote Setting Center ^signed licences" are used for the 
authentication of both communication partners, see section 5.2. 

Both signed licence of a digital meter and signed licence of the Postage Point 
box comprise two components: 

• Data to be signed, consisting of Meter-ID, the publick key for encryption 
(RSA 1024 bit) and the public key for generating digital signatures (RSA 
1024 bit). Due to the public exponent the keys are actuate longer than 
1024 bit; this value only represents the "module" of the key. 

• A digital signature of the data to be signed, applying PKCS#7. 
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sage (with the attribute TYPE= u errorcode") which can be analyzed by the digital 
meter (section 4.13). 

<P-TALK> 

< VERS I ON NUMBER- "1.0" 0WNER= "DEA" USAGE~»1" LANGUAGE- '* de " / > 
<ACTION TYPE-"metersec" STEPS-»6" CURRENTS" STATUS- " invalid" /> 
</HEAD> 

< message TYPE««cert» CRYPT~"no» signature= " 0 " >signed licence of the Postage Point box 

P1,2pb 

</MESSAGE> 

< MESS AGE TYPE="errorcode" CRYPT- "no" S I GNATURE* 0 1 " >Error COC/e< /MESSAGE > 

< signature >Digital signature of the error cocfe</siGNATURE> 

</BODY> 
</P-TALK> 

6.3,3 Second transmission from the digital meter to the Postage Point 

6.3.3.1 Standard communication (STATUS- 'ok") 

A series of necessary data for requesting a new amount of postage is transmit- 
ted to the Postage Point in the second transmission by the digital meter, in the 
following message: 

<P-TALK> 

< VERSION NUMBER- "1.0" OWNER- " DEA " USAGE="1" LANGUAGE = " de " / > 
<ACTlON TYPE="metersec" STEPS-"6« CURRENT- " 3 " STATUS- " ok" / > 
</HEAD> 

<B ° D ImessagE TYPE-»yoursession» CRYPT-»yes» signature^ " l 11 > Session ID code 

SK1pb< /MESSAGE> _ . „ 

< MESSAGE TYPE-"mysession" CRYPT="yes» SIGNATURE^ " 2 « >Request Key 

RKpb< /MESSAGE^ TYpE=p£tampM CRYpT==llyes „ SIG NATURE="3">AcCOUnffran/cmgApB</MSSSAGE> 

< s i gnature >Signature Sig m eteJSK1 PB , RK PB , A PB )< /signature > 

< D ATALOAD > 

<SUMMARY> 

< month > Reference month < /month > 

< product >Product code< / product > 

< numb er >Number of frankings< /number> 
< value > Total revenue < / value > 

</SUMMARY> 
< SUMMARY > 

<MONTH>/?eference month< / month > 

< product >Product code< / product > 

< number >Number offrankings< /number> 
<VALUE>Tdfa/ revenue^ /value> 

<coNTRACT>Cusfomer number of third party< /contract> 

</SUMMARY> 
</DATALOAD> 
</BODY> 
</P-TALK> 

6.3.3.2 Special communication 

The digital meter can cancel the entire communications session in response to 
an invalid message from the Postage Point or at the user's request: 

<P-TALK> 

<VERSION NUMBER- « 1.0" OWNER = " DEA ir USAGE= " 1 » LANGUAGE- - de "/ > 
<ACTION TYPE=»metersec" STEPS="6" CURRENT="3" STATUS = " cancel 11 / > 

</HEAD> 
<BODY> 

paae 90 
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Or 



7 


3 


1 


2 


4 


8 


2 


6 


4 


2 


3 


5 


9 


7 


42 


12 


2 


6 


20 


72 


14 



Example: Identification number 4 
Weighing factors 8 
Multiplication result 32 
Sum of muitipiications + + + + + + +=200 
Division 200 : 11 = 18 remaining 2 

Subtraction 11-2 =9 

Check number 9 



Identification number with check number 473124829 



Product codes for the additional services imprint (only domestic) 

Domestic additional services are identified by a product code, see the following 
table. International additional services will not be coded. 



Aditional service 
product code 


Description (domestic) 


110 


Einschreiben 


111 


Einschreiben Eigenhandig 


112 


Einschreiben Ruckschein 


113 


Einschreiben Eigenhandig 
Ruckschein 


200 


Einschreiben Einwurf 
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